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I. INTRODUCTION 



A. PURPOSE OF THE THESIS 

The Internet has seen exponential growth since 1995 when the Internet 
became commercialized (Rutkowski, 1997). This commercialization has brought 
about opportunities for enhanced capabilities influencing many activities by the 
ability to access information. The World Wide Web (WWW), an application of 
the Internet, created a way to use hyperlinks to visually tap the Internet tech- 
nology. The WWW allowed computer lay people to understand how the Internet 
could benefit them in everyday life through its intuitive use of icons. "The WWW 
created a social turning point for networking equivalent to the transition seen in the 
automobile industry when the Model-T automobile was produced." (Buddenberg, 
1997) The Internet was no longer in the realm of the technically inclined and 
computer savvy’. Greater usage of the Internet has resulted in business being able 
to tap untold markets, increase revenues, and increase profits. Greater usage has 
also resulted in lower unit costs for access. Reduced costs of operating networks 
benefits the owners of the networks by making it cheaper for them to operate and 
by affording them greater resources to invest in enhancements and upgrades to 
meet and exceed user expectations. 
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Commercialization of the Internet did not occur until 26 years after the 
ARPANET, the precursor of the Internet, was launched as marked by the first four 
hosts of the network working. Many people and organizations that are users of the 
Internet today did not have expectations until the last two years of how they would 
benefit from access to the Internet. Users expectations have grown well after the 
base technology matured. Most users did not have expectation nor quite frankly 
could anyone predict how quickly the growth of the Internet occurred. But, this 
growth in usage is predominantly limited to those users with access to land based 
Internet connectivity either through the telephone system or through the terrestrial 
mobile cellular system. There are many potential users that either operate in 
remote areas without access to this land based Internet connectivity or that want 
the flexibility that a space or air wave based wireless infrastructure would provide. 
A similar expansion in usage of space and air wave based media like the expansion 
of the land based media is imminent (Kappel, 1997). Potential users arc beginning 
to demand access to the same capabilities that the land based infrastructure 
supports. Users have expectations of using new technology immediately after that 
new technological idea is conceived and well before the technology is mature. 

One of these of users is the Oceanographic Research Fleet. They want the 
capability to access WWW resources through the Internet while afloat to assist, 
speed, integrate, and coordinate their research (Kappel, 1997). This not for profit 
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organization is acting as a proof of concept test bed for the SEANET project. 
This SEANET project is a collaborative effort designed to foster remote wireless 
connectivity toward the end of meeting the Oceanographic Research Fleets 
demands. They represent any number of groups or individual users that, once 
concepts are proven and infrastructure is established, would benefit from Internet 
access at remote and/or mobile sites not supported by the present land based 
system. This author will examine how the SEANET project can achieve its goals 
of expanding service more effectively thereby meeting users expectations. 

B. SCOPE 

The scope of this thesis will include: (1) a review of how the land based 
Internet expanded, (2) a description of the SEANET project as representative of 
any user in remote areas not supported by wired Internet access, (3) identification 
of the communications resources, infrastructure, and technology needed to provide 
remote wireless Internet access, and (4) a recommended plan for more effectively 
expanding availability of remote access to users demanding access. 

C. METHODOLOGY 

This research will entail conducting a review of the ARPANET to Internet 
expansion to gather lessons learned that can be applied to the SEANET project. 
This research will the provide an overv iew of the system that SEANET represents 
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that provide remote access and identify emerging capabilities that SEANET can 
leverage to more quickly support their users. This research will describe 
techniques for more effectively expanding remote Internet access that will benefit 
the SEANET project. Finally, this research will propose a project management 
plan to provide the controls necessary to ensure the SEANET project meets it 
objectives on time. 
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II. REVIEW OF THE ARPANET TO INTERNET EXPANSION 



A. INTRODUCTION OF THE INTERNET EVOLUTION 

In order to understand how a space or air-wave based (wireless) Internet can 
evolve, it is useful to examine the evolution of the terrestrial Internet. This will 
provide an appreciation of the strategies used to develop the terrestrial Internet and 
provide lessons learned from that process. If applicable, these strategies and 
lessons learned will better allow the SEANET project to meet its goals. By 
tailoring strategies and lessons learned from the evolution of the ARPANET to 
Internet, the SEANET project should be able to effectively implements its 
solutions, meet its user's requirements, and extend the life cycle of the project. 
This will provide a baseline from which to compare the SEANET project 
development proposal. 

This chapter will describe the strategies used to evolve from ARPANET to 
Internet. This chapter will review how the Internet progressed. Finally, this 
chapter will list lessons learned that may prove useful to the SEANET project. 

B. STRATEGIC APPROACHES OF THE EXPANSION 

1. Introduction 

This section will describe the strategic approaches used to evolve from 
ARPANET to Internet. Research into the evolution of the Internet provides three 
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(3) strategic approaches that resulted in the evolution of the Internet. These 
approaches involve the descriptions of the spirit, the standards, and the organiza- 
tion and management style that represent how the Internet evolved. 

2. The Spirit of the Internet Evolution 

The spirit of the evolution was one of pure research initially (Hauben, 
1995). The researchers had an abstract task to develop a manner to conduct 
command and control in the event of a nuclear attack. The researchers felt the best 
way to achieve this task was with a collaborative spirit. They sought open 
participation of any group, person, or idea that would benefit this community of 
researchers having the common interest of connecting computers together. The 
researchers were not interested in only developing a military product. This attitude 
and approach seems odd for a group that is ultimately solving a purpose for the 
military but fits with the time period of the projects beginnings — the mid to late 
1960s. 

3. The Standards of the Internet Evolution 

The standards maintained and demanded of the researchers by themselves 
was critical to the evolution of the Internet. The expectation was that in order to 
make this work at a grand level that "the best academic computer centers" (ARPA 
draft IH-7) must be used. The concept of a "Grand Design" is one of a comprehen- 
sive design that accounts for almost all possible foreseen uses of the technology 
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being developed or the infrastructure being built. Using the best academic centers 
served two purposes: (1) to get the best people and resources working on the 
problem, and (2) ensure development of interactive computer technology occurred 
at a level that was not merely commercially expedient. 

4. The Organization and Management Style of the Internet 
There must be an organizational structure and management style that is 
focused on high level goals. An organization that promotes the project 
development process but is not just immediately concerned with the process 
yielding an instantaneously profitable solution. ARPA, the precursor of the 
DAPRA, charter tends toward the research end of research and development 
focusing on functions as opposed to specific products (Buddenberg, 1997). This 
constitutes a goal oriented process versus a product oriented process. The 
management style must be supportive not directive yet ensure that there is enough 
cohesion to integrate and trigger system planning events after each advance and 
breakthrough. This style is appropriate when not constrained by time nor 
resources. Time nor resources appeared to have been a problem in the late 1 960s. 

C. PHASES OF THE INTERNET DEVELOPMENT 
1. Introduction 

This section will give a description of the phases of the evolution of the 
Internet from its origins as the in the ARPA. The Air Force commissioned Paul 
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Baran of the Rand Corporation to study how to command and control strategic 
nuclear forces after a nuclear explosion (Tappendorf, 1995). Baran determined 
that a packet switched network with no central command center or hub would best 
accomplish this task (Tappendorf, 1995). This lead to network research in how to 
achieve this concept. This research initially was done under the auspices of 
ARPA. The ARPANET phase was followed by the National Science Foundation 
assuming responsibility for the Internet to achieve greater usage of the technology 
for purposes other than military research, command and control. The final phase is 
our present Internet commercial phase. This section will describe what happened 
to provide the basis for SEANET research and development in non-terrestrial 
networks. It will also discuss what went well and not so well during this period. 

2. The ARPANET Phase 

a. What Happened in this Phase 

This phase deals with the period from Baran's research in 1966 to 
1984 when NSF became responsible for the present day Internet. This phase is 
marked by the era of large mainframe computer operated by technically savvy 
programmers for the benefit of the government, universities, and large companies 
that could afford to operate mainframe. 

(1) Research . In 1964 the director of DARPA testified 
before Congress that the next steps in computing would be to link individuals 
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through computers. (Norberg, 1955) This led to the push to link computers via a 
network under the auspices of DARPA's Information Processing Techniques 
Office (IPTO). This resulted in Requests for Proposals (RFP) in networking from 
DARPA in July 1968 (Kulikowski, 1994). Professors and students at UCLA 
"proposed to DARPA to organize and run a Network Measurement Center for the 
ARPANET project" (Cerf, 1993). Research continued at UCLA in the area of 
observing behavior of a networks until September 1969. 2 September 1969 was 
when four Interface Message Processors (IMP-1) computers at UCLA, SRI, 
UCSB, and University of Utah were linked by a circuit to allow for actual study of 
network behavior. 

(2) En gineering . The immediate operation of this four 
node network proved that the packet-switched concept of Paul Baran would work. 
The next step was to get that concept to work on many dissimilar types of 
computers. Steve Crocker, a graduate student at UCLA, led the design of protocols 
for host computers to operate on the APRANET (Tappendorf, 1995). 

(3) Infrastructure . Progress in developing and expanding 
the ARPANET infrastructure occurred slowly. There were many different 
platforms that needed the hardware and software that would use protocols to 
connect the different architectures to the ARPANET (Cerf. 1993). This protocol 
was the Network Control Protocol (NCP) in 1971. There was still little incentive 
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to develop the infrastructure quickly. This incentive appeared in the form of an 
opportunity to demonstrate how the ARPANET worked at the International 
Conference on Computing Communication in 1972. The demonstration showed 
how ARPANET could run applications all over the U.S. The success of the 
demonstration led to the establishment of the International Network Working 
Group (INWG) organized and chaired by Vinton Cerf (Cerf, 1993) to further 
develop the infrastructure. It began to look for other ways to transmit data. It 
launched two projects: (1) satellite transmission of data that became an 

operational network named SATNET in 1976 and (2) a packet switched radio 
network (Tappendorf, 1995). These two projects made NCP unable to meet the 
networks needs. Cerf got placed in charge of the whole Internet after being hired 
by IPTO to further develop the Internet and design protocols for packet radio, 
satellite, and terrestrial Internet. In 1973, Cerfs group developed Transmission 
Control Protocol/Intemet Protocol (TCP/IP). Internet Protocols become opera- 
tional in 1978 (Cerf, 1993). DOD began experimenting with its use and later 
required it for ARPANET. The protocols, that would later result in the network 
later being called the Internet, were bom 1 January 1983 when NCP was 
deactivated and TCP/IP became the protocol on APRANET. In 1984. l!SD(R&E) 
chose ARPANET technology over Autodin II for the Defense Data Network. 
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(4) A pplications . A critical portion of this section are the 



applications that breathed life into the technology. The services that proved 
essential prior to the ARPANET demonstration in September 1972 include the first 
email program by Larry Roberts in 1969, dial-up services for remote terminals 
developed called TELNET in 1972, and file transfer protocols (FTP). Other 
developments that enhanced the Internet's developments include BITNET in 1981, 
a store and forward network; CSNET in 1981, a peer exchange mail service; and in 
1983 the development of the Domain Name Server (DNS) that allowed message to 
ask for directions to its destination thus easing administration of machines and use 
by participants of the network. DNS pairs names with numbered IP addresses to 
assist in routing. 

(5) Scaling Issues . The original design of the network 
address space only considered the need for 256 networks. Based on those times, 
this seemed more than adequate. To handle many local area networks and the 
limitations of the address space, INWG developed the concept of Class A, B, and 
C networks as a means of partitioning the 32-bil address space (Cerf, 1993). 
Today the address space is becoming overwhelmed but IPv6, the next generation 
IP should solve the explosive need for network Ids. 
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b. What Went Well and Not Well In This Phase 
There are three things that went well during this phase. They were 
the pursuit of basic research, the establishment of a grass roots community in the 
field of network computing, and the consolidation of the techniques to move from 
a mainframe world of computing to a distributed form of computing. Basic 
research spawned the development and experimentation with different ways to 
communicate. The relationships developed among the early pioneers of networks 
computing has altered the world through the systems they developed, the 
companies they formed, and the community they fostered. This is also a period of 
consolidation of techniques to handle the ability for computers to communicate or 
transmit data from a large set of architectures, hardware and software techniques to 
a protocol that is still in use today: TCP/IP. The two big payoffs were: (1) TCP 
and IP, as state and stateless machines respectively, laid the foundation for scaling 
and (2) TCP/IP (in the large) is operating system agnostic since these protocols 
have been implemented on dozens of operating systems. The one thing that did 
not go well during this period was implementation of scaling. The original 
pioneers did not comprehend that there would ever be a need for more than 256 
networks back in 1973 since there were so few networks and since no one could 
fathom the impact that networking would have on the world. However, it is 
important for any future development in that the designer must think not only 
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about how to meet the requirement but also how the design might be used for 
purposes not intended or stated in the original requirement. The domain name 
server concept was key to mitigating this scaling problem that is a opportunity for 
network designer of the future. 

DNS went through at least a couple of stages of evolution significant 
to the scaling issue. The first approach was to have a host file in each end system. 
The IP-name pairing is a list in a file on each end system kept its own list. Every 
time a new host was added every end system updated their host files. The second 
approach was the use of a centralized host file at the NIC. New host were added to 
the NIC's host file. Periodically, the host file was FTPed to end systems. 
Centralization caused the updates to always be behind and the overhead that 
resulted, although better than manual updates, was rapidly overtaken by network 
growth. The third stage was the invention of DNS done by Paul Mockapetris that 
is a classical decentralized database (Buddenberg, 1997). 

3. The ARPANET to NSFNET Phase 

The next phase is considered the transition from the ARPANET to the 
NSFNET phase. The NSFNET phase can be considered a time for expanded 
usage. Rather than just use the network for command and control usage, 
researchers of any variety would purchase time to use the super computer centers. 
This move added credibility to the net since the entire research community began 



13 



using the network. It was not just the Defense Department nor just the computer 
science community that saw the advantages of having a new way to communicate. 
Upgrades to the backbone occurred to meet the growing needs of the overall 
community. Higher speed networking and easier access led to more users. These 
users were now able to do more things because of the ability to transfer greater 
amounts of data. This section will describe how the research, engineering, 
infrastructure, and general activities developed during the period of 1984 to 1995. 
a. What Happened In This Phase 

(1) Research . This period represents stability and broad 
based growth of the Internet within the research community. NSF decided to 
become involved in networking with the establishment of five super computer 
research centers connected to each other by a backbone that was linked to the 
ARPANET (Tappendorf, 1995). Researchers could purchase time on this network. 
This NSFNET became very popular and resulted in network traffic exceeding the 
capability of the NSF backbone and ARPANET. The backbone needed upgrades 
that NSF itself was not interested in managing. In 1985, NSF deployed its 
upgraded backbone to a T1 connection that Merit Corp., MCI, IBM. and U. of 
Michigan (U of M) developed (Kulikowski, 1994). By October 1985 most 
ARPANET users were shunted to the NSFNET's T1 connection with the 
ARPANET'S 56Kbps connection being decommissioned in 1990. Merit. IBM. 
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MCI, and U of M later formed a non-profit firm called Advanced Network 
Systems (ANS) that did high speed networking research. In 1987, Computer 
Engineering Research Network (CERN) was created from the merger of BITNET 
and CSNET. There research later developed the World Wide Web technology that 
transformed the Internet. 

(2) Engineering . During the period that the NSF 
influenced the Internet's development there really were not many changes to the 
physical network. NSF, however, did encourage the wide spread use of the Internet 
in the non-commercial, academic, and government research communities. The 
credibility and funding that NSF provided to the Internet fostered growth beyond 
expectations. Every time the NSF increased the size of the backbone, traffic on the 
network increased to fill the capacity. 

(3) Infrastructure . NSF's involvement was critical to the 
improvements in infrastructure. This proved expensive. At first, NSF sought to 
connect researchers directly to one of the five super computer centers. The 
demand for service made the cost of running these connections prohibitive. 
Therefore, NSF began to fund connections to research centers already connected 
the NSFNET rather than directly to one of the five super computers. The final 
improvement in infrastructure to NSFNET occurred in 1991 when NSF connected 
all sites via a T3 connection developed from the research of ANS. The network 
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continued to grow immensely. Accordingly in 1991, NSF created a new network 



called the National Research and Education Network (NREN) to be a non- 
commercial network for high speed networking research. The network was 
becoming unmanageable from NSF's view. 

(4) A pplications . The key application developed during 
this phase is the WWW technology. The technology provided the ability to 
connect documents to other forms of media in the form of a global information 
database. It provided a way for Internet users to use graphics and hypertext. This 
allowed non-technical users to visualize and search for information in a very 
intuitive ways. This further increased usage of the Internet and forced NSF to 
reconsider its role in the Internet. 

(5) Scaling Issues . NSF realized their network was 
operating differently. Therefore, they announced they would no longer allow 
direct access to the backbone. Instead access would be purchased from a 
contractor representing NSF. NSF gives the following reasons for this: (1) the 
government does not want to be in the communications business and (2) this 
allows for commercialization of the net as the government restricts commercial 
use. The result is the commercial Internet is bom. 
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b. 



What Went Well and Not Well In This Phase 



NSF realized the net was working differently and not along the 
established purposes of this governmental foundation. This revelation marks the 
end of this phase and the beginning of the transition to the commercial Internet. 
1988 to 1993 was a period of major growth from the order of magnitude of 
thousands of users to millions of users (Rutkowski, 1997). The research and 
commercial aspects of the network began leaping ahead of the military sector with 
NSF upgrading to T1 and T3 connections while DOD was still using 56kbps 
connections (Buddenberg, 1997). 

4. The Internet Phase 

The Internet Phase began with the NSF contracting with access providers in 
order to get government out of the communications business and to allow 
commercialization of the net. This last phases of placing the Internet in the 
commercial sector provides the basis for the free-wheeling nature of the Internet 
today. It directly placed the marketing of products and services based on market 
forces that exploit Internet technology in the private sector after the infrastructure 
of building the Internet had been established. 

a. What Happened In This Phase 

(1) Research . This phase is still evolving. The research 
that occurs is in the areas of high speed networking, modifying the address space 
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to deal with the ever increasing market demand for network identification address 
and user identification address, and how to standardize and consolidate the best 
platforms, protocols and channels for efficient use of Internet resources. The 
concept of ubiquitous computing is for people to communicate, collaborate, work 
and play no matter what platform they use nor whether they are on land, at sea, or 
in space above the earth. The SEANET project is an example of the type of 
research being conducted to achieve the integration and expansion of Internet 
access across the globe. 

(2) En gineering . Before solutions to evolve the Internet 
into a ubiquitous communications medium can occur, consensus must develop 
between the ever increasing number of community of users or stakeholders with an 
interest in the Internet. The Internet is not just a network for the use of the 
technologically savvy. The many stakeholders include governmental bodies across 
the globe, international and multi-national corporations including broadcast tele- 
vision, telecommunications, and satellite providers, the academic and research 
communities, and private citizens from every walk of life. These varied stake- 
holder’s desires all must be negotiated prior to designing, building and 
implementing an> adjustments or major enhancements to the Internet. Therefore, 
solutions are falling into the realm of the world political structure because all 
stakeholders realize that far too much money and far too much power can be 
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shifted by the use and abuse of the Internet. Consensus must be achieved before a 
solution arrives. This impacts the infrastructure. 

(3) Infrastructure . The infrastructure that supports the 
Internet is undergoing consolidation and integration in order to take advantage of 
economies of scale. Basic economics and market forces are causing different 
stakeholders to follow different strategies to compete in providing what customers 
want and meeting demand. Examples of this include the merger of MCI (one of 
the first providers of Internet access) and British Telecommunications (BT). In 
1993, when the NSF subsidies ended, all the non-profit ISPs either reinvented 
themselves as for-profit, taxpaying entities or they got bought up by for-profit 
corporations. None of the formerly non-profit ISPs folded. The significance is 
that the non-commercial acceptable use policy went away and the five-year NSF 
subsidy period turned a neat military R&D program into an industry. Partnerships 
are developing to generate the skills and capital to invest in the large dollar game 
of evolving the Internet to the world's needs not just any one isolated group of 
individuals needs. This business process of adjusting the structure to meet the 
visualized end state is occurring right now. How this plays out is yet to be 
determined. Market forces have proven the most efficient way to achieve the 
highest quality products and services at the most economical prices as long as 
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there is competition. This author believes that this will continue to be the case. 
This might alter the products and services currently available. 

(4) A pplications . The following is a list of the major 
applications and services that are being provided on the Internet. These 

applications and services become possible mainly due to higher capacity, varied 
classes of service, enhanced protocols, added complexity, transition to multimedia 
technologies, and transition to truly mobile clients and servers. The present and 
emerging generic applications fall into these major categories (Catlett, 1993): 

1 . Text file transfer (FTP) 

2. Electronic mail (SMTP) 

3. Remote login (TELNET) 

4. Video teleconferencing 

5. Interactive visualization 

6. Composite imaging 

7. Multimedia mail 

8. Character data transfer 

9. Multimedia database access 

10. Collaboration technology 

11. Image transfer 

12. Distributed computing 
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Services that continue to evolve and emerge include providing security, 
providing directory services, and providing network management. Security 
services include confidentiality, authentication, integrity, access control, and non- 
repudiation (Kent, 1993). Directory services provide for users to locate and 
identify network objects. These directory services include a way for users to find 
other users on a local host called FINGER, a way to allow for querying a single 
database on a specified machine called WHOIS, a method of dividing Internet 
domain networks into distributed sections to ease location of any section quickly 
and reliably called DNS, a two-step process to locate users by searching databases 
called NETFIND, X.500 (a single, unified, worldwide system that completely 
describes all OSI resources), and WAIS (to target coordinated access to 
information). The final service category is that of network service. The primary 
network service in the Simple Network Management Protocol (SNMP). SNMP 
provides for remote management of network resources from anywhere on the 
network. 

b. What Went Right In This Phase 

What went right in this phase is a question is still up for debate as the 
wide spread commercial use of the Internet is so immature. It is clear that the 
Internet was ready to go commercial. NSF did a service by contracting out the 
management and access of the Internet to allow for commercial use. Internet 
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Service Providers (ISP), by accepting NSF money, had to work under the NSF’s 
acceptable use policy that excluded commercial use. This problem disappeared 
when the NSF money and acceptable use policy disappeared. This commercial- 
ization has spawned new business, careers, lifestyles, and way to collaborate. It 
has also raised questions of free speech, security, and the appropriate use of 
technology. The impact thus far affects every human endeavor. This should 
continue but it too early to provide a qualitative assessment. 

D. LESSONS LEARNED 

1. Open System Approach 

Various sources reflecting on the history of the Internet discuss the value of 
using an open systems approach. In this context, these sources do not merely 
discuss the limited idea of "open systems" as a hardware and software inter- 
operability issue. Rather, the concept is one of a total system approach using 
products, processes and people that are open to innovative ideas, methods and 
products. This concept is more rightly viewed as "open participation" in the 
process. This far more encompassing concept of an "open system" is much more 
an attitude than a product, process or protocol. 

This approach manifested itself by the true democratic way the people with 
a common goal were free to suggest ideas and implement solutions. These 
solutions were briefed to the community and essentially were voted on. The 
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voting took the form of computer code being run to demonstrate the real world 
implementation of the idea (Buddenberg, 1997). This democracy resulted from an 
established method of capturing ideas and disseminating through the establishment 
of the RFCs. RFCs were not only an historical record but more importantly were a 
mechanism to quickly get ideas and solutions out in the open for discussion and 
critical review. This proved essential to the development of the Internet and 
reinforced the relationships and trust among members of the community. 

2. Fielding Plan of Host Computers 

An important decision during implementation was the sequencing of which 
nodes to bring up first on the network. The first node was the host at UCLA. This 
served as the Network Measurement Center to capture congestion data (Hauben, 
1995). Statistics would be run on this data to assist in bringing up future hosts and 
in Network Management and Control. The other three original hosts each had 
specific purposes as well. The Stanford Research Institute (SRI) host served as the 
Network Information Center (NIC), the world's first anonymous FTP server. The 
University of California Santa Barbara (UCSB) host provided interactive mathe- 
matics. The University of Utah provided graphics (Cerf, 1993). 

3. Grand Design Versus Operational Network 

A third lesson learned was the impact of the decision over the initial design 
of the network. The network designers "struggled between a grand design and 
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getting something quickly" (Crocker, 1993c). The initial design has impact not 
only on how quickly the product is developed but also on what adjustments or 
upgrades can or should be made later as the network evolved. Although these 
pioneers tried to think as broadly as possible they ultimately settled for a working 
network. This led to the problem of scaling that the Internet is facing today. "The 
somewhat embarrassing thing is that the network address is under pressure now." 
(Cerf, 1993) Had the initial pioneers thought more grandly or at least developed a 
plan to scale the Internet from the beginning, the expanding scale of the Internet 
would not need to be addressed today. 

The lesson is to contemplate all potential users of your technology and 
protocols. Plan for the use of your technology and protocols by the intended users 
of your network but also develop a plan to scale your network up and out for 
purposes not initially intended. This suggest to design a network that can be 
scaled at a later time rather than to build a network that has excessive capacity 
today. This also serves the purpose of generating broader based acceptance and 
support of the technology being designed. This prepares for when/if the 
technology is used for commercial purposes, that the project this technology is 
initially intended for may benefit by lower unit costs. Risk needs to be analyzed 
not only for project failure but also for successes beyond ever imagined. The 
answer to the question "what if everyone in the world has a computer and all are 
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connected to the Internet at the same time?," would have provided some insight 
into the scaling question. 

4. Request For Comment (RFC) 

The fourth lesson learned is to capture a record of all meetings and critical 
reviews of the project. Although this is a basic concept, it should not be 
overlooked as it serves multiple purposes. 

1. It provides a basis for people in the community that did not 
participate in meetings or project review sessions to understand what 
has transpired and in what order decisions have been made. 

2. Documentation is typically a weakness of any project. 

3. It captures history. 

4. If there is any question, at a later date, over intellectual property 
rights and rights of authorship, RFCs provide a way to clarify those 
issues. 

Ideally, meetings should be recorded by videotape to capture not only 
words but body language and mannerisms. Written minutes are essential to 
capture exactly what is discussed. The Network Information Center and the RFC 
is an ideal vehicle to support this purpose. RFCs were posted on-line at SRI that 
ran the NIC. RFCs were stored in the world's first anonymous FTP server. This is 
in contrast to other standards organizations where standards were copy-righted 
material that arc sold for prices to be able to sustain the operations of the standards 
organization. 
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5. Management Controls and Guidance 

Key to development of the Internet was the management controls and 
credibility lent to the network developers. ARPA and NSF provided critical 
guidance at critical moments in the history of the development that brought about 
success. However, project control was not designed into the development from the 
start. Instead "Smart management sense [that] paved the way" for the scientists to 
create the ARPANET. This management sense was provided in the way of people 
providing comments and influencing the community throughout the project. This 
author interprets this to mean that there was little consideration for building in life- 
cycle management from the start in a self-governing manner. The researchers had 
the benefit of being associated with organizations that had the breadth, skill and 
pragmatism to interject control at just the right time. This proved very beneficial 
and should be built into the design of any future network projects. 

6. Transition Plan 

The final lesson learned is that the ARPANET to Internet project did not 
have a cohesive acquisition life-cycle project plan. The project evolved with the 
right people providing fortuitous guidance at just the right time. This loose type of 
project management process although flexible, did not lend itself to meeting any 
meaningful cost, schedule, or performance parameters. However, due to the scope 
of the participants, the varied technology, and the complexity involved in the 
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Internet project at this point in 1988 when NSF took over, maybe the best that 
could have been expected of NSF was to provide the coherence to all project 
participants so development could flourish at the expense of what looks to be a 
poorly controlled project (Buddenberg, 1997). 
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III. OVERVIEW OF THE SEANET PROPOSAL 



A. SEANET PROJECT BACKGROUND 
1. Purpose 

The purpose of this project is "to provide transparent connectivity for ships 
in the oceanographic research fleet routinely." The oceanographic research fleet 
personnel use the Internet and WWW on land for their research and they want to 
be able to use it when underway at sea. They can communicate while underway 
but each vessel cannot share data very well with the other research vessels or with 
land-based sites due to system incompatibilities. 

Currently deployed data communications limit the task of best 
supporting oceanographic research today. Although data commun- 
ication to and from ships is common, each ship has its own way to 
send email, transfer files, or perhaps provide interactive services. 

The communications cost for these services are high and users often 
experience low throughput and a variety of communications systems 
problems. (Kappel, 1997) 

Technical support at sea is spread thin. Typically, each remote unit will 
have one technician that has to keep all the oceanographic equipment operational 
along with being the network manager. Remote network management is not in the 
system at this time (Buddenberg, 1997). 
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2 . 



Project Participants and Roles 



a. Introduction 

This section describes those organizations that are involved in the 
SEANET project and the roles that each organization plays. The participants are 
organized into two levels of participation: primary and supporting. The primary 
participants generally have a specific role or function, are required to provide a 
deliverable product, and they have an interest in the Oceanographic Fleet. The 
supporting participants provide limited products and services and generally do not 
have an interest in the Oceanographic Fleet other than through providing computer 
communications to the fleet. 

b. Primary Participants 

This material is a recap of the Seanet proposal submitted to the 
Office of Naval Research (ONR) in 1997 to develop a capability for the 
oceanographic research fleet. 

Joint Oceanographic Institute (JOI) provides liaison and are a 
primary SEANET project coordinator. They interact with federal agencies and the 
science community. The also coordinate with the Advisory' Panel. 

Woods Hole Oceanographic Institute (WHOI) shares duties as a 
primary SEANET project coordinator and is the responsible agent for the 
Shipboard Communications Node (SCN) development. 
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Lamont-Doherty Earth Observatory (LDEO) is the responsible agent 
for INMARSAT-B procurement. They are also responsible for shipboard system 
installation and testing. 

OMNET, Inc. is the responsible agent for the SEANET Operations 
Center. They are also responsible for billing and use accounting of the SEANET 
network. They also provide value added services as necessary. 

Naval Postgraduate School (NPS) is the responsible agent for the 
Shipboard Implementation Laboratory. They monitor emerging technology. They 
also act as the liaison agent with the US Naval Research and Development Center 
(NRaD). 

Individuals from these organizations recognized an internet 
extension would be a significant enhancement to the oceanographic research fleet 
mission but budgetary sponsors did not until 1997. Sponsorship in the form of 
money and commitment occurred in 1 996 that funded research and development in 
1996. (Buddenberg, 1997) 

c. Supporting Participants 

The following groups and organizations provide services and 
products that the SEANET primary participants are leveraging to achieve their 
project goals. These supporting participants are as follows: 
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COMSAT is a satellite communications vendor. They will provide 
reduced rates for access to their satellite communications channels. They provide 
engineering support and potentially enhanced services as satellite technology 
improves. 

MAGNAPhone provides 20% hardware discounts. They will assist 
with engineering support and they benefit by having key input into their product 
design from the SEANET prototypes. 

MCI, Inc. will provide free circuits and act as the SEANET project's 
terrestrial Internet Service Provider. 

The US Naval Research and Development Division (NRaD) is a 
component of the NCCOSC. They will provide technological transfer of military 
unique solutions that have application to non-military users will underway at sea. 

NAVOCEANO is an organization involved in oceanographic 
research that is interested in lending support to the SEANET project for transfer 
back into the military once proof of principle occurs. They are peers to university 
oceanographic research personnel. 

3. Project Strategy 

Seanct participants want to replicate what NSF did with the regional ISP, 
start a commercial industry, but in remote regions. They want to provide at-sea 
internet service the way terrestrial service is provided today. 
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4. 



Project Objectives 



The SEANET project has six primary objectives. 

a. Provide Communication Channels 

The project is interested in integrating ships underway with land 
based stations using various radio links. Those presently known are INMARSAT- 
B Channel at 64kbps, cellular telephone at 9.6kbps, AMSC satellite channels at 
4kbps, and High Frequency radio channels at 2.4kbps. 

b. Provide Reasonable Data-Communication Rates 

The project aims to provide incentives for oceanographic research 
fleet users to utilize the SEANET network for their research. This is not only to 
increase the community of users so that there is acceptance of the technology but 
also to generate the market forces that will result in lower rates unsupported by 
subsidies. This is an issue of economy of scale. The oceanographic research fleet 
benefits by pooling its own resources. Furthermore, if a generic capability is 
developed that is useful to other users beside the research fleet, the research fleet 
can benefit by buying sendees at marginal costs. 

c. Provide Network Operation 

Essentially, this entails providing the functions of an Internet Sendee 
Provider (ISP) dedicated to the SEANET project. These functions include point of 
presence for all wireless channels, firewalls to limit access into the SEANET for 
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only authorized users, network management, standard terrestrial ISP services, and 
maintaining a shore-base SCN. This support is a form of venture capital that 
assists in growing an industry. 

d. Provide Network Information Services 

These services include shipboard installation support, 24 hour 
customer services for ships underway, business services for billing and accounting 
for carrier use, and web page development, maintenance and distribution. These 
services are another form of venture capital. 

e. Integrate Internet Over HF Radio 

Tailor technology already developed by the US Navy through 
technology transfer to integrate Ship-based and Shore-based stations in the 
SEANET network. 

f Establish SEANET Testing and Technology Laboratory 

The Naval Postgraduate School provides graduate education to 
members of the Department of Defense that have a professional interest in mobile 
platform communication. Therefore, NPS has the space, testing equipment, and 
personnel that naturally provide value to the project through testing of new 
techniques and technology. Testing can involve new technologies such as new 
communications channels, remote network management, and equipment upgrades. 
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5. 



Objective Limitations 



There are three key limitations to achieving these objectives as the project is 
currently scoped. They involve infrastructure, protocols, and a business model. 
The following are infrastructure limitations. 

1. AMSC links suffers from propagation delays that severely degrades 
performance of highly interactive applications. This link is func- 
tional but only for coverage in North America and to 100 miles off- 
shore. It is only narrow-band voice capable at this time. 

2. The INMARSAT-B link also suffers from propagation delays but 
offers global coverage except at high latitudes. 

3. High-Frequency (HF) offers global coverage but atmospheric 
conditions can result in coverage being blocked out at specific ship 
or shore locations. 

4. The cellular technology requires a grid of receivers in close 
proximity to the moving ships. There is not a cellular grid at sea or 
in remote areas like the terrestrial cellular grid in built up areas to 
pass signals to the ground or satellite system. 

5. All these links are all circuit-switched point to point voice telephone 
type systems versus packet-switched IP type systems. Therefore, 
adjustments must be made. 

The protocol limitations assume ethemet-like connectivity. Ethernet uses 
three way handshakes that do not fit the intermittent service and batch orientation 
of radio links nor does it fit into the telephone system channels. None of the links 
above provide a presence all the time like a wireline ethemet system. 
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There are three business model limitations. The connectivity providers 
need to move from the packet-switched mentality from the circuit-switched mind- 
set. A community of users must be nurtured to demand the capability and this can 
only done with incentives to pursue Seanet goals. Commercial ISP must be 
convinced through the prospect of profits and technical capability that the Seanet 
goals are feasible. 

6. Project Organization 

This project is organized as a collaboration. Two of the primary partici- 
pants (Maffei and Heinmiller) felt the project would be "more successful if there 
was a community wide consortium." The project participants have different skill 
and traits that lend themselves to an Integrated Product Team (IPT) approach. The 
project group seeks "all parties interested in pursuing the goals [of the project] ...in 
a consensus style. The project group realizes that planning is critical to a 
successful IPT approach but project coordination is vitally important. The project 
group assigned responsibility for technical control to Mr. Maffei and community 
coordination to Dr. Ellen Kappel. 

B. NETWORK DESCRIPTION 

This section will describe the SEANET network. It consists of shore-based 
systems, ship-based systems, and the communication channels that provide 
connectivity between ship and shore. 
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1 . 



Shore-Based System 



This portion of the network provides the interface between the SEANET 
and the traditional Internet. This is achieved by a Network Operations Center 
(NOC) run by MCI that uses a router and the SEANET Wide Area Network to 
connect to the Internet. OMNET will run the Network Information Center (NIC) 
services using their own host computers connected to the NOC. OMNET also has 
the accounting and billing responsibilities to ensure that users are being charged 
accurately based on established rates. A frame-relay network will connect to the 
hosts that transfer to the Up-link/Down-link points depending on the type of 
communications channel the users chooses or is forced to use to access the Shore- 
based systems. The following diagram (Figure 1) provides that graphic for the 
functions that occur on land and the points that transmit to and from the ships 
underway. 

2. Ship-Based System 

Figure 2 shows the ship-based system include all the hardware and software 
that necessary to best optimize the connections from the ships underway through 
the various communications channels available. Each research vessel will possibly 
have multiple researchers working different projects from nodes connected to the 
shipboard Local Area Network (LAN). The SEANET Communication Node 
(SCN) will be the front-end tool to optimize connections between the various 
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Figure 1. Shore-Based System 




Figure 2. Ship-Based System 

nodes on the ship's LAN with the various communication channels available to 
transmit and receive from shore-based stations. 
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IV. APPLYING LESSONS LEARNED TO SEANET 



A. STRATEGIC APPROACHES APPLIED TO SEANET 

1. Introduction 

This section analyzes the SEANET approach to achieving its stated goals in 
terms of the strategic approach the Internet used. This section will analyze in 
terms of the spirit of the SEANET expansion, the standards of the SEANET 
expansion, and the organization and management style of SEANET. 

2. The Spirit of the Seanet Expansion 

The overall spirit of the SEANET is very similar to the Internet Evolution 
but towards different ends. The Internet initially was geared toward pure research. 
The SEANET project has been focused on providing a product to achieve the set 
purpose of supporting Oceanographic Research. This project is not as concerned 
with research in communications purely for research sake. However, the SEANET 
project is very similar to the Internet expansion in how it approaches the task. The 
SEANET project follows a collaborative approach making itself available to 
leveraging the talents and resources of those with interest in supporting 
Oceanographic research. The collaborative spirit proved essential to the Internet 
and likewise should prove to be a critical way for the SEANET project to be 
successful. 
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3 . 



The Standards of the SEANET Expansion 



SEANET is building a computer communication network for the Ocean- 
ographic Research Fleet. They accept participation of those organizations and 
individuals with interests in the Oceanographic community. It is important to get 
the user involved in defining requirements so that the right product is built for the 
right reasons. It is equally important to have the right people build the product. 
The Internet evolution set as a standard to use "the best academic computing 
centers" to design and build the Internet. This author has not seen a similar stated 
standard espoused by the SEANET project. This is not to suggest that the 
organization and personnel participating in the SEANET project are not capable or 
competent in their respective areas of expertise. This issue is that unlike the 
Internet evolution, the SEANET project is not using the "best academic 
communication centers" to design, develop, and build their networks. The 
question is does the SEANET project participants have the past performance and 
reputation that matches the Internet collaborators in the area of computer 
communication? The SEANET project should consider soliciting participation 
from a larger circle of academic and commercial research center conducting 
wireless networking research. The credibility gained and academic support might 
prove useful. 
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4 . 



SEANET Organization and Management Style 



The final strategic area to analyze involves the organization and 
management style of the SEANET project. The Internet project like the SEANET 
project uses a collaborative style. Internet received critical guidance at critical 
points in time necessary to evolve the Internet. The issue is will SEANET be as 
fortunate to receive the same "smart management sense" at critical points in time 
to have an equally or more successful network development. The SEANET 
Advisory Panel should provide a role towards providing management guidance as 
the project progresses. The issue is why not develop a flexible management plan 
and flexible project controls from the start that supports the development. This 
project is in the Program Definition and Risk Reduction (PDRR.) Phase of its life- 
cycle and such a management and project control plan integrated into the system 
design should prove beneficial in keeping cost, schedule, and performance goals 
on target. 

B. LESSONS LEARNED OF INTERNET APPLIED TO SEANET 

1. Open Systems Approach 

This section analyzes the SEANET project's Open Systems Approach. This 
approach proved invaluable to the Internet development when coupled with 
utilization of the best academic computing centers. The SEANET project proposal 
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states and appears to actively solicit the participation of any organization or 
individual with an interest in oceanographic research. The critical aspect of this 
project, the communication system being produced, provides a function that any 
group not just the oceanographic research fleet could utilize. Therefore, SEANET 
should seek the participation and actively solicit any organization or individual 
with an interest and proven background in wireless computing. The project 
participants have been seeking this participation but it is the opinion of this author 
that the project participants have not developed a formal marketing plan with 
someone whose sole responsibility is to market the project and solicit development 
participants. This expansion of participation could be manifested by other long 
haul communication companies, other satellite companies, and other technologies. 
The list could include AT&T, GTE, Orbcomm, Teledesic, Globalstar, TRWs 
Odyssey as well as other academic computer communications researchers. This 
expansion should include the many different emerging technologies like Low 
Earth Orbiting (LEO) Satellites during the design phase. This would allow these 
technologies to be easily and more inexpensively incorporated as a planned 
product improvement when these technologies mature. Creating modules for 
emerging technologies in the SEANET Communications Node that arc inactive 
until those technologies mature will provide the SEANET project greater 
flexibility to adapt and greatly improve throughput at a later time while 
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minimizing the cost of redesigning the system after it has been built. Inclusion of 
emerging technologies of LEOs during the design phases would provide an easier 
transition to those mediums once the technologies become operational in the out- 
years beyond the funding period of this project. Greater participation of 
companies with capabilities already represented in the project should promote 
competition that might translate in lower rates to users and would ensure that there 
are second sources for products and services should the sole source be unable to 
deliver. 

2. The Plan For Fielding 

The next lesson learned from the Internet development involved the fielding 
plan of the nodes on the network. The initial host computers of ARPANET were 
brought up on the network in a specific order for well-intentioned reasons. The 
SEANET project is a prototype with a well diagrammed network topology. The 
fielding plan for the prototype system is not a significant issue since the entire 
land-based infrastructure portion of the system must be in place prior to the ship- 
based infrastructure can connect through the SEANET to the Internet. The land- 
based and ship-based portions can be installed simultaneously but not connected. 
The SCN controls the integration of both the land and ship based segments of the 
network. The issue of the order of activation of the nodes is not as critical as its 
was for the initial host computers on the ARPANET. 
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3. 



Grand Design vs. Operational Network 



This section analyzes the decision of building a network with a grand 
design or a network that is operational. The SEANET proposal established as a 
goal to integrate using common software, hardware, and protocols. Therefore, the 
SEANET proposal seeks an operational network. This foregoes an opportunity to 
design, build, and operate a network having greater appeal to a larger community 
than the Oceanographic Research Fleet. Greater appeal developed from a network 
with a larger scope or grander design would have the benefit of attracting more 
users to the network. If well managed and scaled, a larger network should reduce 
the unit costs to users and might provide even greater research resources from 
organizations presently participating in the SEANET project. 

4. Documentation 

This section analyzes the documentation and critical external reviews that 
the SEANET project is subjecting itself. SEANET has proposed establishing an 
on-line repository for project documentation. They also will undergo periodic 
review from an advisory panel to generate constructive feedback involving all 
aspects of their system development. At this early stage of the project, what 
cannot be answered is how the project participants will incorporate constructive 
feedback into design reviews. This suggests a need for configuration control 
especially since new technologies later developed might result in product 
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improvements subsequent to completion and fielding of the network. It is more 
costly to make changes to a product the later those changes are incorporated in the 
life-cycle of the product. SEANET should not only capture and incorporate 
approved changes quickly but do as thorough a job as possible in planning the 
easiest and cheapest way to incorporate the changes. 

5. Management Controls 

This section analyzes the management controls. This is the area that is most 
critical to ensuring the project meets cost, schedule, and performance goals. The 
project has identified a project schedule. The project schedule already must be 
readjusted due to delays in funding. However, there does not appear to be any 
controls established to monitor cost and schedule and to sample performance. 
Monitoring expected cost and schedules versus actual cost and schedule would 
provide statistical ways to understand the implications of changes in cost and 
schedule. The concept of Earned Value would provide the project a way to 
understand how changes in cost and schedule impacts performance. These 
controls established early would support the project participant's ability to 
objectively determine the trade-offs to make based on user requirements. 

6. Incentives 

A technique DARPA used to speed the implementation of infrastructure 
was to hold a demonstration of the capabilities that the ARPANET could provide. 
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DARPA set a date in advance to spur those individuals working on the ARPANET 
to speed development. It was a way to use the human nature of the participants 
against themselves. It established a mark on the wall to jump over. This 
expectation to perform and not let the community of users down motivated the 
participants to work towards a goal, finish those aspects of the project that were 
not complete and make enhancements to benefit the project. This technique would 
be a useful tool for the SEANET participants. A demonstration of the SEANET 
capabilities at a renowned conference would serve to not only provide an incentive 
to spur development but what also be a way for the SEANET project to advertise 
their capabilities. This announcement of capabilities could generate support 
behind that already achieved to increase the user base and could result in attracting 
other functions and skill sets the project participants might lack to make the project 
overwhelmingly successful. 

C. CONCLUSION 

This chapter analyzed the SEANET project in terms of its Strategic 
approach and in terms of the lessons learned from the Internet development. The 
SEANET project is off to a good start based on its stated objectives. The have 
incorporated some of the same strategic approaches that the Internet used during 
development and have benefited from its lessons learned as well. There are 
differences as well that the SEANET project has not incorporated and would be 
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advised to do so. The primary approach that would be wise to enhance is in the 
area of soliciting the assistance of more organizations and personnel with a proven 
reputation in wireless computer communications. The primary lesson learned 
involves developing management controls early in the life-cycle to assist meeting 
cost, schedule, and performance measures. The next two chapters will provide 
insight into why a project management plan would be useful and how to develop a 
project management plan that establishes management controls to enhance the 
effectiveness of the SEANET project. 

The question raised is what should happen next, how should it be 
accomplished, and why should these steps be taken. The design reviews by the 
project collaborators that are occurring in the early fall of 1997 using IPT approach 
is a natural way to integrate and develop the detailed plans that provide the 
direction to the project. These design reviews are a perfect opportunity to take an 
inventor)' of the skills and functions that the project has at this point in its 
development, determine deficiencies across all areas of the development that 
includes project policy, system engineering, software management, test and 
evaluation, manufacturing and production, logistics, cost estimation, financial and 
contract management, and develop techniques to meet these deficiencies. The 
project chose to act in a collaborative fashion. As a result, each project participant 
is responsible for being involved in the pain-staking process of developing the 
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inventory, designing solution or determining the skills that must be present to 
overcome skill and function deficiencies. An experienced project manager would 
help provide the business and management focus. The project appears to have the 
technical areas covered but there appears to be some integration and planning 
assistance needed. This is a critical point in the project because what develops out 
of the design reviews will be what the project builds. The design reviews can be a 
catalyst for coordinating and integrating the project or it can be an opportunity to 
participants to focus on a narrow scope of issues that are important today but 
forego the opportunity to develop long and short range plans that meet the projects 
ultimate goal of providing remote access to users in a cost efficient manner. 
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V. PROJECT MANAGEMENT PLAN (PMP) 



A. INTRODUCTION 

This project beckons for an overarching Project Management Plan (PMP). 
A cohesive life-cycle management plan was a weakness in the development of the 
Internet. It should be addressed by the SEANET project to improve the 
effectiveness of the project and speed development. This plan would leverage the 
lessons learned from the ARPANET to Internet expansion. It would tailor life- 
cycle management plans that have proved effective in delivering projects that meet 
cost, schedule or performance goals. The SEANET project recently received 
funding to pursue its goals. The SEANET project will begin a series of design 
reviews to finalize roles, responsibilities, and establish cost, schedule, and 
performance measures. A detailed project plan would prove useful to more 
effectively enable the participants to meet their goals. This chapter will discuss the 
rational for establishing such a plan that would make the SEANET project more 
effective and timely. This chapter will discuss the purpose for a PMP and the 
general procedures to follow. 
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B. PURPOSE 



1. Background of the PMP 

The SEANET PMP provides the direction and strategy for the SEANET 
program. While the PMP should be done for all programs, experience shows that 
it is particularly important for projects that integrate many communities that find 
themselves with common goals. If the PMP is done properly, much of the 
information contained in it can be summarized to form the System Development 
Plan (SDP). The PM is responsible for completing the planning activity in support 
of the program. 

2. Purpose of the PMP 

The purpose of the PMP is to: 

1. Provide the SEANET program strategy and plans of action for 
attaining program objectives. 

2. Identify responsibilities all staff, partner & support organizations, 
customers, and contractors who will work on the program. 

3. Define the resources required to execute the program. 

4. Provide a master schedule of tasks and program milestones. 

3. Project Manager's Responsibility' 

The PM serves as the integrating force throughout the program, and it is the 
PM’s responsibility to develop and maintain the PMP with functional and technical 
support. The PMP should be consistent with the program baseline used to manage 
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program performance requirements, cost and schedule throughout the program. 
The SEANET project has various individuals whose roles is to coordinate specific 
aspects of the project. It does not appear due to the collaborative nature of the 
SEANET project that any one person is acting in the role of Project Manager 
whose sole purpose is to maintain an overarching management perspective in 
meeting cost, schedule or performance objectives. This authors suggests that the 
project members should establish this role and develop a project management plan 
(PMP). The following is a recommended PMP. The SEANET PMP should 
accomplish the following: 

1 . Organize and staff the program. 

2. Support effective communication of program information. 

3. Establish budgetary and time estimates for overall program and 
major work elements. 

4. Establish a common core set of management metrics from which to 
evaluate and control software development. 

5. Manage performance, cost, and schedule risks. 

6. Provide a quantitative framework from which progress can be 
assessed, variances can be calculated and analyzed, and alternative 
courses of preventive or corrective action can be evaluated. 
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C. PROCEDURES 



The PMP should be designed to facilitate program coordination, 
communication, planning, and control rather than provide technical direction to 
participants. Therefore, it should only developed to the level of detail necessary to 
apportion the work among the functional activities within the SEANET 
community and other parties involved in the program. The following paragraphs 
are key considerations for successful development and execution of a PMP: 

1. Migration Strategy 

The PMP should support the selected migration strategy. Migration 
system/application selection should be based on the following factors: 

a. Functional : To be selected as a migration system/ 

application, the information system will have to be based on defined work 
processes and will have to be based on the degree to which the system meets the 
information needs of users within and across functional areas. A decision should 
be generally supported by the functional user community representing project 
stakeholders. 

b. Technical : The system/application can evolve (migrate) to 
be supported by the DoD Technical Architecture Framework for Information 
Management (TAFIM). Each of these systems/applications must be integrated 
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into the Defense Information Infrastructure (DII) Common Operating Environment 
(COE) and Common Data Environment (CoDE). 

c. Programmatic : Office of Naval Research will undoubtedly 
require a functional economic analysis that documents a reasonable range of 
alternatives that meet both functional and technical objectives. The alternatives 
must be within programmatic constraints (resources, schedules, and acquisition 
strategy), and justify adopting the migration system/application for the community. 
The migration system/application selection can be based on an abbreviated 
functional economic analysis. 

d. Data : The ability to transition to data standards is a 

fundamental requirement for an information system in order for it to be selected as 
a migration system. Applications should lend themselves to data sharing within 
their design. Migration plans must include transition to commercial industry 
standard data and shared data concepts. 

2. Project Strategy 

The PMP should support the program strategy that will be used to design, 
develop and deploy the SEANET project, e.g.. grand design, incremental, 
evolutionary or other. In selecting the appropriate strategy, the unique 
circumstances of individual programs should be considered and the strategy 
chosen must remain consistent with the project's acquisition policy. 
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a. In determining which activities apply to each increment, the 
key question to be answered is: what are the objectives of the increment? From 
this point, more detailed planning would be required. Define each system 
increment in terms of the requirements it will meet and its composite hardware, 
software, and data base components. To be useful, an increment should conform 
to the following rules: 

(1) Satisfy a subset of the requirements to be met by the 

complete system. 

(2) Constitute an entity that can be used to demonstrate to 
the customer that a functional subset of the requirements has been met. 

(3) Represent a logical division of the design of one or 
more increments or builds. 

(4) Provide a solid core for meeting the requirements 
assigned to the remaining builds. 

b. Successful execution of an incremental or evolutionary 
program strategy requires a number of changes to relationships and practices 
common to more conventional or "grand design" programs: 

( 1 ) The need for a closer, interactive set of relationships 
among the functional user, the developer, the independent evaluator, and the 
supporter. 
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(2) The need for streamlined procedures to allow each 
increment of capability to progress rapidly through definition, design, 
development, testing, fielding, operational evaluation and integration into the 
operational environment. 

3. Software Metrics 

Software metrics provide a quantitative framework from which to evaluate 
and control software development or integration and may be divided into three 
general categories: management, requirements, and quality. 

a. Management metrics are measures that help determine 
progress against the plan. Trends in management metrics support forecasts of 
future progress, early trouble detection, and realism in plan adjustments. 

b. Requirements metrics pertain to specification, translation, and 
\olatility of requirements. 

c. Quality metrics deal with testing and other software technical 
characteristics. 

A common core set of management metrics for software should be 
developed early in the development cycle. 
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VI. PROJECT MANAGEMENT PLAN FORMAT 



A. INTRODUCTION 

This chapter provides the SEANET Project participants with a format to 
develop a plan to provide management control over their activities. This will assist 
the project members in meeting cost, schedule, and performance objectives. This 
should prove helpful to the project as they recently received funding to pursue 
their objectives in establishing connectivity for mobile platforms (research vessels 
underway at sea) with the terrestrial Internet. 

B. SEANET PROJECT MANAGEMENT PLAN FORMAT 

1. Purpose 

State the purpose of the Seanet Project Management Plan (PMP). 

2. Objectives, Scope, and Major Activities 

A brief description and statement of purpose of the SEANET Project being 
developed or acquired. Reference SEANET Mission Need Statement. 

3. Organizational Responsibilities and Relationships 

Identify the management team/staff, acquisition agent, other support 
organization elements and contracts that support the effort. Reference the 
SEANET Project Manager's Charter. 
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4. Management Approach 



Summarize all major tasks to be performed, program management structure, 
approach, stakeholders, schedule, and required resources. 

5. Migration Strategy 

Summarize factors for selection: 

1. Indicate how the proposed system will support the "to be" work 
processes and the degree to which it meets the information needs of 
users within and across functional areas. 

2. Indicate how the implementation/deployment of the proposed system 
will ensure compatibility with components of by the Information 
Infrastructure and the Operating Environment. 

3. Summarize alternatives that meet both functional and technical 
objectives, and are within programmatic constraints (resources, 
schedules, and acquisition strategy). Justify adopting the selected 
migration system. 

4. Indicate the ability to transition to data standards, and show how 
applications lend themselves to data sharing within their design. 

6. Acquisition Strategy for Migration Systems 

Summarize acquisition considerations for selection: 

1. Indicate how existing Information Systems, peripherals or other 
assets in place will be used to support the proposed migration 
system. 

2. Describe existing indefinite delivery and indefinite quantity (1DIQ) 
or other contracts that will be used/considered to satisfy 
requirements that cannot be met through existing assets. 

3. Identify existing contracts for the system, when awarded, and any 
issues involving awards. 
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4. Identify any potential acquisition issues. 

5. Describe the level of proprietary technology and related impacts to 
the SEANET project. 

6. Indicate whether existing contracts contain language requiring the 

use of data standards and the use of Enterprise Data Model 

structures. 

7. Defense Information Infrastructure 

Describe how the proposed system will support the level of integration 
required. Indicate how the proposed system will evolve to be supported by the 
integrated, standards-based architecture prescribed for. This is important since the 
oceanographic fleet might need to communicate and integrate with defense or 
government agencies such as the U.S. Coast Guard that also use standards-based 
architectures. 

8. Program Strategy 

Present the appropriate program strategy that will be used to design, 
develop, and deploy the Information System. A discussion of the grand design, 
incremental, evolutionary and other program strategies is contained in this DOD 
Acquisition Deskbook (Defense Acquisition Deskbook, 1997). 

9. Data Standards 

Indicate the ability to implement standard data structures (models as well as 
data standards), and how applications lend themselves to data sharing within their 
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design. The following are sample considerations for determining data migration 
and standardization feasibility. 

1. Indicate if and how data are separated from applications (e.g., use of 
APIs, DBMSs). 

2. Indicate the extent to which the Information System is modeled 
(logical and physical). If both logical and physical models exist, 
indicate whether they are mapped to each other and in what tool. 

3. Indicate whether the migration system logical data model is mapped 
to the SEANET Enterprise Data Model and the extent to which the 
migration Information System uses standard data and implements 
Enterprise models. 

4. Indicate to what extent the data elements (standard and non- 
standard) are registered in a Data Repository (DR), and, if 
applicable, whether the system is registered as a user of the standard 
data elements in the DR. For Information System using non- 
standard data elements and structures, indicate whether a data 
migration strategy exists and, if so, is documented and approved in a 
Project or Functional Data Administration Strategic Plan (DASP) 
Action Plan(s) (if so, attach appropriate extracts from the DASP). 

5. Indicate the extent to which data are shared with other applications 
both received from as well as provided to other applications). Where 
data is shared with other applications, indicate whether documented 
translations exist and where they are recorded (e.g., repository, 
system code, etc.). 

10. Metrics 

Identify a common core set of management metrics, considering key 
measures such as: 

1. Schedule and Progress - regarding completion of program 

milestones, significant events, and individual work items. 
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2. Growth and Stability - regarding stability of required functionality or 
capability and the volume of software delivered to provide required 
capability. 

3. Funding and Personnel Resources - regarding the balance between 
work to be performed and resources assigned and used. 

4. Product Quality - regarding the ability of delivered product to 
support the user's need without failure, and problems and errors 
discovered during testing that result in the need for rework. 

5. Software Development Performance - regarding the developer's 
productivity capabilities relative to program needs. 

6. Technical Adequacy - regarding software reuse and use of approved 
standard data elements. 

11. Schedule 

Provide time schedules for accomplishing tasks. 

12. Resource Requirements 

Identify resources required to support the development effort. 

1 . Manpower . Summarize target and projected manpower 

requirements. 

2. Funding . Summarize target and projected funding requirements. 

13. Risk Management 

Identify any special needs or characteristics that could represent areas of 
risk. For example, identify any needs for new technology development, and 
schedule dependencies external to the program's control, and any special skills 
required to perform the work. 
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1. Identify any risks that may have a potential impact on program 
performance, cost and schedule. 

2. Prepare a profile for each risk including: probability, cost impact, 
schedule impact, earliest expected visible symptom, and action 
plan(s) to be invoked upon detection. 

3. Update and monitor risk plans to account for new potential and 
manifest risks. 

C. CONCLUSION 

The establishment of a Project Management Plan (PMP) is critical to 
ensuring that the project can meet its baseline goals. Without such a plan there 
will be no control measurement to objectively determine when or if the project is 
meeting cost, schedule, or performance goals. Furthermore, a PMP can alert 
project members quickly when critical aspects of the project create a risk that 
impacts the entire project. Management controls enable the project members the 
opportunity to make informed judgments in reducing risk and making adjustments 
to ensure the project goals are met as originally planned. The SEANET Project is 
currently organized as a collaborative effort. Therefore, a SEANET PMP should 
be developed and agreed upon by all participants to ensure success. There is no 
value in developing a plan that will not be followed. The SEANET project is at a 
point in the life-cycle that provides for a natural way for such a plan to be 
developed and for someone with credibility and authority to be designated as the 
proponent of that plan. The SEANET project already has had to adjust their 
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schedule due to external funding delays. This is a very reactive position to be in. 
A PMP would assist in identifying project problems so the project participants can 
take corrective action quickly to ensure the project is kept on track. 
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VII. SUMMARY 



A. THESIS SUMMARY 

The Internet has transformed and continues to transform every human 
endeavor. Commercialization of the Internet is largely responsible for this 
phenomena. The Internet had proved to be a case of how a limited purpose 
technology evolves into a technology with global impact. This occurred by 
government funding and nurturing research and development and transferring that 
technology into the commercial sector. The market based commercial sector 
through competition proves to increase efficiency, improves quality, and provides 
goods and services at attractive prices. 

There are still many areas of the Internet that require improvement and 
enhancements to meet and exceed user's requirements. One area is involves the 
concept of "ubiquitous computing and communication." Many areas of the globe 
do not have access to the wired Internet due to their physical location on the globe 
or due to lack of infrastructure that to support Internet access. Generally, these 
areas are at sea away from the coastlines of developed countries, on land in remote 
or undeveloped areas, or in space. People everywhere are beginning to expect to 
have Internet access wherever and whenever they are. 
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The SEANET Project is an attempt to provide Internet access to remote 
users not connected to the wired Internet. It took the wired Internet 26 years to 
become mature enough and cost efficient enough to transition to the commercial 
Internet. Once the Internet went commercial the uses, applications, and demand 
for access has increased at amazing rates. Unlike the developers of the Internet, 
the SEANET project does not have the luxury of 26 years to mature and evolve 
their technology. Users now have higher expectations of using the Internet when 
and where they want. 

This research explored how the SEANET project can more effectively 
expand availability of remote access to the Internet to meet users demands. It did 
so by using the evolution and transition of the ARPANET from a military project 
for command and control of strategic nuclear forces to the present day Internet to 
understand lessons learned that should apply to the SEANET project. This 
research also described a way for the SEANET project to better achieve its goals 
through the adoption and implementation of a project management plan. The 
SEANET Project is still in the early stages of designing its system. A 
comprehensive plan should better define project participants roles, should foster 
better communication and an understanding among all participants of what and 
why they are building this network, and it should provide the framework for the 
project to better adapt to changing requirements. Using an IPT approach to 
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develop the plan, a set of management controls and milestones should ensure the 
project meets its objectives. Should the project participants determine they are not 
meeting their objectives, they can more quickly adjust their scope. The PMP 
developed can act as a framework that the project participants use throughout the 
project life-cycle to plan execute, control and adjust their activities. 

B. RECOMMENDATIONS 

There are four major recommendations that resulted from this author's 
research. These recommendations are taken from their successful use in other 
projects as reflected in the lessons learned from the Internet evolution or from 
practices utilized in both government and/or commercial project management 
disciplines. The recommendations provide a way to enhance the effectiveness of 
developing a wire-less capability. The following provides a way to organize these 
recommendations. 

1. Use the Lessons Learned that Apply to SEANET 

• Continue to use the IPT approach and actively seek the participation 
in and feedback from all stakeholders. 

• Develop a fielding plan. 

• Develop an operational network but maintain a grand design or 
architecture based outlook. 

• Enable access to project documentation. 

• Develop management controls. 
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2 . 



Develop a Strategic Vision 



• Provide an understanding of what the project wants as a result that 
captures the emotions of project participants and possible users. 

• Create an environment that attracts quality people and organizations 

• Review and update the management style and organization so the 
appropriate approach is used through the entire project life-cycle 

3. Implement a Project Management Plan 

• Assign a project manager with proven experience and credibility. 

• Develop a formal PMP during the upcoming design reviews utilizing 
the framework provided. 

• Develop clear roles and expectations for each project participants. 

• Develop a migration strategy early that transitions project through 

different project life cycle phases. 

• Establish a statistical control . plan for cost, schedule, and 

performance goals. 

• Develop consequences for not meeting cost, schedule and 

performance goals. 

4. Develop a Marketing Plan 

• Assign responsibilities to market the project to attract people, ideas 
and funding. 

• Conduct a demonstration at an internationally recognized computer 
communications symposium to motivate participants to achieve a 
certain capability by a certain time and to generate broad interest in 
the project. 
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The SEANET project has immense possibilities to impact all human 
endeavors to an even greater extent than the Internet. There are opportunities to 
enhance the effectiveness of the project with a more structured approach to the 
planning and control of the project. 

C. FURTHER RESEARCH 

The SEANET project is seeking to solve a problem for the oceanographic 
research fleet. However, the solution has benefit to many different user both 
commercial, governmental, and private. There are many areas and disciplines that 
can be explored to benefit this project and to link application to other human 
endeavors. 

1. What organizational staffing considerations are there that would 
enhance the SEANET Project? 

2. What considerations should there be made to test and evaluate the 
project through the entire project life-cycle? 

3. What logistical support considerations need to made to implement 
and support the project? 

4. What are the implications to the project regarding manufacturing and 
production planning? 

5. What contract types by phase enhance the project as it evolves and 
transitions to the commercial sector? 
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APPENDIX. ACRONYMS AND ABBREVIATIONS 



ANS 

ARPA 


Advanced Network Systems 
Advanced Research Projects Agency 


BITNET 


Because It's Time Network 


CoDE 

COE 

CREN 

CSNET 


Common Data Environment 
Common Operating Environment 
Computer Research Engineering Network 
Computer Science Network 


DARPA 

DII 

DNS 

DOD 


Defense Advanced Research Projects Agency 
Defense Information Infrastructure 
Domain Main Server 
Department of Defense 


EV 


Earned Value 


FTP 


File Transfer Protocol 


IBM 

ICCC 

IDIQ 

IMP 

INWG 

IPT 

IPTO 

IPv6 

ISP 


International Business Machines 

International Conference on Computing Communication 

Indefinite Delivery and Indefinite Quantity 

Integrated Message Processor 

International Network Working Group 

Integrated Process Team 

Information Processing Techniques Office 

Internet Protocol version 6 

Internet Service Provider 


JOI 


Joint Oceanographic Institute 


LAN 

LDEO 

LEO 


Local Area Network 
Lamont-Doherty Earth Observatory 
Low Earth Orbital 
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NCP 

NIC 

NOC 

NPS 

NRaD 

NREN 

NSF 


Network Control Protocol 

Network Information Center 

Network Operations Center 

Naval Postgraduate School 

Naval Research and Development 

National Research and Education Network 

National Science Foundation 


OSI 


Open System Interconnection 


PDRR 

PM 

PMP 


Program Definition and Risk Reduction 
Project or Product Manager 
Project or Product Management Plan 


RFC 

RFP 


Request For Comments 
Request For Proposal 


SCN 

SDP 

SMTP 

SNMP 

SRI 


Shipboard Communications Node 
System Development Plan 
Simple Mail Tool Protocol 
Simple Network Management Protocol 
Stanford Research Institute 


TAFIM 

TCP/IP 

T1 

T3 


Technical Architecture Framework for Information Management 
Transmission Control Protocol / Internet Protocol 
a dedicated line that can carry 1.544 megabits per second 
a dedicated line that can carry 44.736 megabits per second 


UCLA 

UCSB 


University of California at Los Angeles 
University of California at Santa Barbara 


WA1S 

WHOI 

WWW 


Wide Area Information Services 
Woods Hole Oceanographic Institute 
World Wide Web 



74 



LIST OF REFERENCES 



Advanced Projects Research Agency, ARPANET Completion Report, draft, 1968. 

Buddenberg, Rex, Personal Interviews and Comments, January-September 1997. 

Catlett, Charles E., Internet Evolution and Future Direction, Internet System 
Handbook, Addison-Wesley Publishing Company, Inc., 1993. 

Cerf, Vinton, How the Internet Came to Be, "The On-Line User's Encyclopedia," 
by Bernard Aboba, Addison-Wesley, November 1993. Available at 
http .//info, soc.org/ guest/zakon/ Internet/History/ How _the_ Internet _ 

came_to_Be. 

Crocker, Steve, Comments on Michael Hauben's History of the Internet paper, 

1993. 

Defense Acquisition Deskbook, U. S. Department of Defense, 1997. Available at 
http: //'www. deskbook. osd. mil 

Hauben. Michael, History of ARPANET, Columbia University, New York, 1994. 
Available at http://www.dei.isep.ipp.pt/docs/arpa.html 

Rappel. Ellen, el al, SeaNet: Extending the Internet to the Oceanographic 
Research Fleet, Joint Oceanographic Institute, 1997. 

Kent. Stephen, Architectural Security , Internet System Handbook, Addison- 
Wesley Publishing Company, Inc., 1993. 

Kulikowski. Stan. A Timeline of Network History, Educational Research and 
Development Center, University of West Florida, 1994. Available at 
http: //info. isoc. org/guest/zakon/ Internet/History/Timelinc _of_ 

Network _ H is ton • 

Mockapetris. Paul V., Directory Services, Internet System Handbook. Addison- 
Wesley Publishing Company. Inc., 1993. 



75 



Norberg, Arthur, Judy O'Neill, A History of the Information Processing 
Techniques, Office of the Defense Advanced Research Projects Agency, 
The Charles Babbage Institute, Minneapolis, MN, 1992. 

Rutkowski, Tony, Internet Trends - Internet Hosts 1989-1997, General Magic, 

1997. Available at http://www.genmagic.com/Internet/Trends/slide-3.html 

Tappendorf, Sean, ARPANET and Beyond. Available at http.V/clavin.music. 
uuic. edu/ sean/Internet Jiistory. html # illustrations . 



76 



INITIAL DISTRIBUTION LIST 



1. Defense Technical Information Center 2 

8725 John J. Kingman Road, STE 0944 

Ft. Bel voir, VA 22060-6218 

2. Dudley Knox Library 2 

Naval Postgraduate School 

411 Dyer Rd. 

Monterey, CA 93943-5 1 0 1 

3. Prof. Carl R. Jones (Code SM/Js) 1 

Naval Postgraduate School 

Monterey, CA 93943-5103 

4. Prof. William J. Haga (Code SM/Hg) 1 

Naval Postgraduate School 

Monterey, CA 93943-5103 

5. Prof. Rex A. Buddenberg (Code SM/Bu) 1 

Naval Postgraduate School 

Monterey, C A 93943-5103 

6. CPT Marko J.E. Nikituk 3 

321 Reid Lane 

So. St. Paul, MN 55075 



77 



DUDLEY KNOX LIBRARY 




3 2768 00340863 4 



